The invention relates generally to a graphical user interface system and more particularly to a system and method for a user interactively to computer-control an electronic testing system.
In a typical experiment or testing environment, there is a device or object under test, a means to stimulate the device under test, and a means to measure the response of the device to stimulation. The process of stimulus/response testing is typically followed by an analysis phase to extract specific information from the response measurement.
In a computer-based instrument environment, a host computer is connected to the stimulus and response instruments. This computer, commonly called the controller, controls the operation of the test instruments and can be used to perform the analysis of the response data. The most common interface for connecting the controller to the instruments is the GPIB (General Purpose Interface Buss) or IEEE 488 standard.
The most common approach to control of this computer-based stimulus/response testing has been to write a program in BASIC, FORTRAN or other high-level programming language to control the instrumentation and, in a similar manner, to write a program to perform the response data analysis. The instrument control programs conventionally include subroutines, or drivers, which interpret the control expressions in the high-level language and convert them into the communication protocol required to control the instrument. For certain instruments, drivers may also report the state of the instrument, such as the control settings and error status information, as well as the response data that an instrument may detect. These drivers are essentially similar to the computer operating systems used to communicate with peripheral devices, such as terminals, disk drives and magnetic tape drives.
BASIC is typically the language of choice for test system developers and users, because it is easy to learn by novices and is interactive. Nevertheless, the writing of control and analysis programs can become quite tedious and the programs are often difficult to modify. The user must communicate with the test instrumentation in terms of its conventional control settings, e.g. amount of vertical offset, vertical scale factor, etc. The user must understand not only how to control the test instrument but how to communicate the desired controls in the programming language.
Many high-level languages have also been extended to provide means for graphically displaying data returned from test instruments. The programs employ windowing modules or subroutines to convert acquired data, e.g., digitized signals, from the coordinate system of the data, e.g., time vs. voltage, into the coordinate system of the display device (CRT). With data transformed into display coordinates, graphing modules interpret various language commands and apply the commands to the display-coordinate data and produce instructions in a form that the display device requires to render a graphical representation of the test data.
High-level language elements, windowing modules and graphing modules have been widely used to produce graphical representations of data stored in computer memory. They have also been used in conjunction with graphic input devices, e.g., a joystick, mouse, etc, which controls a display cursor, to interpret the cursor's screen location in terms of the coordinate system of the display data. This type of display system enables the user to display the stored data in different scales, but the resolution of the data displayed is limited to that which is stored. Zooming in on a portion of a waveform cannot add any more detail about the waveform than was originally stored. Also, the stored data is limited to the record length of data stored. Thus, zooming out beyond the dimensions of the stored data does not make more data available. To remedy both of these problems requires the user to reprogram the test instrument to acquire a new set of data.
In conventional manual operation of test instruments, the user operates the test instrument controls interactively in response to the graphical presentation of the data. The operation of programmable test instruments controlled by high-level programming languages, however, requires forethought and calculation. Thus, programmable test instruments are difficult to use in an interactive manner. The user can set goals in terms of the display data, but must transform these goals into terms of test instrument settings in order to act. If more than one instrument is being used, each must be set separately. Similarly, if the manner of analysis of the returned test data is to be modified, the analysis routines must also be reprogrammed. All of this entails much complexity, and requires substantial expertise, time and careful work to accomplish successfully.
Software systems are also known which enable a user to model and simulate systems on a computer and interactive display. An example of such a system is BLOSIM, a general purpose simulation program for sampled data systems described in D. G. Messerschmitt, "Blosim--a Block Simulator," Dept. of Electrical Engineering, Univ. of California--Berkeley (June 7, 1982). A BLOSIM user partitions a system to be simulated into small pieces implementing elementary parts of the system, each piece called a block, and provides a simulation program for each block. The user also provides a program that defines the topology of interconnection of the blocks. BLOSIM then handles the details of the actual interconnection and execution of the blocks. BLOSIM was not designed to be used as a test instrument control program. Moreover, the topology of the blocks must be recompiled each time a change is made in the system under test. Additionally, application of BLOSIM to actual systems becomes very difficult as the topologies become increasingly complex. Hence, within the known state of the art, BLOSIM is not applicable to test instrumentation control.
Accordingly, a need remains for an improved method and apparatus for controlling test instrumentation and analyzing signals.